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EXECUTIVE  SUMMARY 


Changes  in  technology  and  fundamental  restructuring  and  downsizing  of  the  military  call  for 
fresh  thinking  about  how  the  military  accomplishes  its  goals  and  objectives.  The  challenge  is  to 
adapt  and  use  organizations,  processes,  and  rapidly  changing  technologies  to  achieve  greater 
effectiveness  and  quality  at  reduced  cost.  Organizations  that  master  change  will  continue  to 
improve  their  operational  effectiveness,  while  those  failing  to  reengineer  their  practices  and 
policies  will  gradually  loose  their  competitive  edge  in  our  ever-changing  world. 

The  purpose  of  the  War  Reserve  Materiel  Capability  Assessment  (WRM-CA)  program, 
sponsored  by  the  Air  Force  Research  Laboratory  (AFRL),  is  to  enable  the  Air  Force  to  track, 
assign,  and  greatly  increase  the  visibility  of  War  Reserve  Materiel  (WRM)  around  the  world. 
Currently,  there  is  no  Air  Force  system  to  organize,  collect  and  utilize  WRM  data  in  a  way  that 
can  be  advantageous  to  potential  users.  The  systems  in  place  today  are  ad  hoc  and  tracked  with 
current,  commercial  off-the-shelf  software  systems.  These  off-the-shelf  systems  have  limited 
functionality.  Research  into  the  subject  of  post  cold  war  WRM  has  identified  the  need  for 
additional  capabilities.  WRM-CA  provides  the  war  fighter  with  planning  and  visibility 
capabilities  that  far  out  perform  any  other  system  in  place. 

The  development  of  the  system  was  beised  on  the  integration  and  analysis  of  information 
collected  from  AFI  25-101,  WRM  Tiger  Team  minutes  and  fi:om  users  at  numerous  bases 
located  throughout  the  Continental  United  States  (CONUS),  United  States  Air  Force  in  Europe 
(USAFE),  and  Pacific  Air  Forces  (PACAF),  as  well  as  first-hand  observation  of  the  WRM 
processes  at  those  bases.  In  addition  to  describing  the  current  process,  users  identified  process 
problems  and  improvement  ideas  for  use  in  the  development  of  WRM-CA.  In  some  cases,  the 
improved  system  was  then  presented  back  to  the  users  for  their  review  and  verification  to  ensure 
a  solid  foimdation  fi-om  which  to  build  towards  the  final  demonstration  version  of  WRM-CA. 

While  the  basic  WRM  process  will  remain  relatively  constant  into  the  futuie,  the  technologies 
available  to  implement  the  process  will  change  dramatically.  With  the  year  2010  selected  as  the 
first  implementation  target,  the  focus  of  the  Year  2010  Concept  of  Operations  (CONOPs)  is  to 
implement  these  current  or  anticipated  technologies.  As  time  progresses  beyond  2010,  evolving 
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technologies  will  replace  the  Year  2010  technologies  as  appropriate,  further  enhancing  the 
effectiveness  of  the  WRM  process.  These  enhancements  in  WRM  use  will  minimize  the 
deployment  footprint,  reduce  the  reaction  time  required  to  satisfy  a  deployment  tasking,  and 
finally  utilize  the  millions  of  dollars  of  WRM  assets  not  being  put  into  use  today  during 
contingency  operations. 

The  intended  goal  is  to  have  an  Air  Force  wide  system  that  will  interface  with  other  pertinent  Air 
Force  legacy  systems  that  will  give  the  user  current  WRM  information  and  allow  users  to 
manipulate  that  data  when  required  and  authorized.  Ultimately,  when  WRM-CA  is  used  in  the 
way  it  is  intended,  it  will  support  the  operation  by  not  only  reducing  the  deployment  footprint, 
but  also  deploying  organizations  will  trust  the  serviceability  of  the  WRM  assets  and  deployed 
commanders  will  be  able  to  plan  for  the  use  of  WRM  in  their  operations.  Thus,  the  possibility 
exists  that  Air  Force  tactical  operations  in  the  area  of  responsibility  could  begin  sooner  than  they 
could  before. 
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1.  INTRODUCTION 

The  lack  of  visibility  and  the  inability  to  assign  WRM  assets  positioned  around  the  world  has 
limited  the  value  and  benefit  of  the  millions  of  dollars  invested  in  the  Air  Force  WRM  program. 
Unit  Deployment  Managers  (UDMs)  do  not  have  insight  to  the  status  of  the  WRM  resources, 
unit  commanders  do  not  have  faith  in  the  assignment  process,  and  Major  Command  (MAJCOM) 
WRM  managers  lack  the  necessary  tools  to  assign  the  resources  on  a  unit  priority  basis. 
Accordingly,  there  is  a  need  for  a  decision  support  tool  to  provide  visibility  of  WRM  resources 
and  enable  efficient  assignment  of  those  resources  to  deploying  units. 

WRM-CA  is  a  decision  support  tool  developed  by  Synergy,  Inc.  under  contract  with  AFRL.  The 
purpose  of  this  tool  is  to  provide  decision  support  to  logistics  planners  with  the  resulting  benefits 
of  reducing  the  size  of  deployment  packages  by  locating  and  assigning  WRM  to  deploying  units. 
Previous  experimental  versions  of  WRM-CA  were  developed  to  demonstrate  to  the  Air  Force 
that  a  tool  of  this  nature  could  assist  in  the  deployment  of  units  in  a  timelier  manner,  but  those 
systems  had  no  substance  to  their  functionality.  Finally,  after  a  long  development  and  research 
contract,  the  software  can  now  demonstrate  the  capabilities  necessary  to  prove  its  effectiveness 
and  potential  benefit  to  war  fighters  and  logisticians. 

The  tool  will  allow  users  to  select  sites  fi'om  a  map  and  view  the  exact  details  of  the  WRM  at 
each  site.  The  user  can  view  the  National  Stock  Number  (NSN),  condition,  serviceability,  status, 
maintenance  record  and  other  detailed  information  of  each  WRM  item.  Once  a  deployment  plan 
is  loaded,  it  will  be  shown  on  the  map.  Details  of  each  unit’s  needs  are  displayed.  Users  can  see 
what  WRM  is  available,  and  then  assign  it  to  deploying  units.  WRM  shortfalls  are  displayed  if 
the  necessary  items  are  unavailable  or  out  of  service.  Using  this  information,  a  unit  can  reduce 
its  footprint  by  minimizing  overlap  of  materials.  Since  the  material  is  already  on  location  or  in 
the  theater  of  operations,  there  is  no  need  for  the  deploying  imit  to  take  up  valuable 
transportation  assets  with  the  same  items.  In  this  maimer,  units  will  know  exactly  what  WRM 
will  be  onsite  waiting  for  them,  and  what  they  will  need  to  bring. 

WRM-CA  will  increase  effectiveness  of  deployment  plans  by  reducing  the  amount  of  material 
units  need  to  take  with  them.  Unit  leaders  will  be  confident  in  the  status  of  WRM  at  the 
receiving  site  because  they  can  see  that  it  is  there  in  good  condition  and  assigned  to  them.  WRM 
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assignment  will  no  longer  be  a  function  of  the  haphazardness  first-come-first-served  policy  that 
currently  governs  WRM  use.  WRM  will  be  used  effectively  and  accurately  with  the  use  of  this 
tool. 

2.  PROBLEM  ANALYSIS 

2.1  Problem  Statement 

Ever  since  the  beginnings  of  the  Cold  War  between  the  United  States  (US)  and  the  then  Soviet 
Union,  the  United  States  Air  Force  (USAF)  has  been  prepositioning  wartime  equipment  all  over 
the  world  for  use  in  contingency  operations.  Eventually  to  become  known  as  War  Reserve 
Materiel,  these  assets  were  originally  going  to  get  the  North  Atlantic  Treaty  Organization 
(NATO)  and  US  forces  started  earlier  in  the  defense  of  Western  Europe  and  parts  of  Asia.  This 
equipment  was  Operations  Plan  (OPlan)  driven;  which  meant  it  was  positioned  at  numerous 
locations  to  a  level  commensurate  to  the  level  of  wartime  activity  occurring  at  that  base  or 
region.  Millions  of  pieces  of  equipment  comprised  these  stocks. 

Early  in  the  1990s,  the  Soviet  Union  ceased  to  exist,  taking  with  it  the  threat  of  worldwide 
domination  of  a  communist  regimen.  Until  this  time,  the  Air  Force  WRM  program  was  well 
maintained.  Equipment  was  serviceable  and  trustworthy.  After  this  time,  though,  stocks  all  over 
the  world  became  less  and  less  of  a  priority  since,  at  that  time,  the  need  for  quick,  world  wide 
deployments  had  diminished. 

By  the  end  of  the  1990s,  the  Air  Force  WRM  program  was  in  need  of  improvements.  Funding 
for  repair  and  replacement  was  shrinking  and  not  many  war  planners  even  understood  that  WRM 
existed.  With  these  issues  at  hand,  the  WRM  Tiger  Team  in  October  1999  included  the 
following  statement  in  its  report  to  the  Air  Force  WRM  Executive  Review  Board: 

‘‘The  AF  WRM  program  does  not  have  the  flexibility  to  support  both  deliberate  and  crisis 
action  planning  and  execution.”  With  that  in  mind,  AFRL  and  S)mergy,  Inc.  developed  an 
even  more  detailed  problem  statement  that  exposed  the  real  core  of  the  problem: 

“Due  to  lack  of  visibility  and  effective  use  of  serviceable  WRM  and  prepositioned  assets 
located  around  the  world,  millions  of  dollars  in  Air  Force  funds  are  spent  in  the  purchase. 
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positioning,  and  maintenance  of  assets  not  used  in  the  execution  of  contingency 
operations.” 

From  these  two  statements,  the  AF  came  to  the  realization  that  an  all  encompassing  WRM 
visibility,  assignment  and  management  tool  was  needed.  The  funding  wasted  year  after  year  on 
unused  equipment  was  becoming  staggering.  Also,  with  the  advent  of  the  Air  Expeditionary 
Force  (AEF)  concept,  and  the  speed  required  to  get  wartime  operations  started,  the  Air  Force 
would  need  serviceable  and  dependable  WRM  assets  for  contingency  use. 

2.2WRM-CA  Theory 

The  theory  behind  WRM-CA  was  straightforward:  by  developing  an  automated  system  that 
could  display  Total  Asset  Visibility  (TAV),  provide  a  capability  to  assist  base  level  WRM 
managers  in  the  management  of  WRM  stocks,  provide  a  capability  to  track  the  assigned  use  of 
WRM  assets  and  present  a  capability  assessment  of  WRM  inventories  within  a  WRM  Unit  Type 
Code  (UTC),  we  could  better  utilize  the  existing  worldwide  WRM  stocks  and  greatly  reduce 
home  station  deployment  timelines  and  logistics  footprints. 

It  was  clear  what  the  technical  prerequisites  were  for  the  visibility,  management,  and  assignment 
process  capabilities.  The  capability  assessment  fimction  was  going  to  be  more  involved  to 
produce  due  to  its  dependency  on  other  Air  Force  legacy  computer  systems.  With  those  issues  in 
mind,  the  development  of  the  Air  Force’s  first  WRM  management  tool  began. 

2.3  Defining  User  Requirements 

Throughout  the  research  into  the  WRM  issue.  Synergy  contractors  foimd  many  of  the  personnel 
addressed  more  than  willing  to  provide  input  into  the  system  development.  The  fimstration  was 
evident  at  the  lack  of  attention  the  worldwide  WRM  program  receives  as  well  as  the  wasted 
potential  of  the  program.  It  was  with  these  thoughts  in  mind  that  Synergy  personnel  initiated 
information  gathering  interviews  with  potential  WRM-CA  users. 

The  first  information  gathering  trip  took  Synergy  personnel  to  Ramstein  AB,  Germany  where 
they  met  with  the  head  of  the  USAFE  WRM  program.  Major  Kirsten.  The  main  issues  of 
concern  were  inventory  levels  at  the  WRM  warehouse  in  Sonem,  Luxemburg.  An  inventory 
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tracking  system  as  well  as  a  better  way  to  track  the  maintenance  histories  of  the  equipment  were 
required.  The  Microsoft  Excel  spreadsheets  used  for  inventory  tracking  were  working,  but  the 
majority  of  time  in  Germany,  provided  no  capability  to  see  real  time  information  on  the 
equipment  under  his  charge.  Also,  due  to  the  magnitude  of  the  storage  facility,  a  way  to  track 
and  review  inventory  changes  and  maintenance  record  updates  was  also  required.  After  five 
days  in  Germany  and  Luxemburg,  the  WRM-CA  team  came  home  with  good  ideas  on  where  to 
start  development. 

The  next  data  collection  trip  took  the  WRM-CA  team  to  the  Republic  of  South  Korea.  The  bases 
visited  were  Taegu  and  Kimhae.  Personnel  from  units  that  had  a  stake  in  the  WRM  process  were 
interviewed  and  asked  several  questions.  The  subject  matter  of  the  questions  ranged  from 
describing  the  WRM  process  as  you  know  it  to  where  they  felt  the  issues  lay  in  the  WRM 
process.  Some  major  themes  that  were  repeated  were  the  support  they  received  or  did  not 
receive  from  headquarters  in  the  way  of  funding,  personnel  and  technology  that  could  help  them 
do  their  job  better.  The  technology  subject  was  the  target  which  Synergy  personnel  expanded 
upon.  Synergy  found  that  WRM  equipment  visibility,  assignment  tracking  and  up-to-date 
equipment  tracking  was  lacking.  The  units  in  Korea  felt  if  an  automated  tool  could  be  developed 
that  could  alleviate  some,  if  not  all,  of  those  issues;  it  would  be  well  worth  the  money  to  create. 
Upon  their  return  firom  Korea,  the  WRM-CA  team  expanded  more  on  the  visibility  and 
assignment  process. 

Before  the  next  data  collection  trip,  a  quality  first  proof  of  concept  “draft”  of  WRM-CA  was 
developed.  It  included  many  of  the  features  the  users  required  plus  a  few  more.  This  version  of 
WRM-CA  became  a  player  in  the  Joint  Expeditionary  Force  Experiment  (JEFX)  2000  beginning 
in  May  2000.  JEFX  2000  included  various  operating  locations  where  base  and  MAJCOM  level 
users  had  ample  opportunity  to  test  and  discuss  the  WRM-CA  system.  Represented  during  JEFX 
were  Aviano  AB,  Italy;  Barksdale  AFB,  LA;  Davis  Monthan  AFB,  AZ;  and  Air  Force  Staff 
personnel  located  at  the  Pentagon.  While  exercising  WRM-CA  during  JEFX  2000,  all  the 
players  from  the  before  mentioned  bases  had  the  chance  to  use  and  test  WRM-CA.  Use  of  the 
system  generated  feedback  and  determination  of  system  requirements.  Changes  required  to  the 
system  were  then  made  during  the  course  of  the  exercise.  Information  vital  to  the  development 
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of  WRM-CA  was  collected  during  JEFX  2000.  Much  of  the  data  was  input  into  the  system  to 
help  improve  its  functionality. 

Although  the  WRM-CA  team  did  not  get  a  chance  to  speak  to  more  potential  users  of  the  system 
than  they  desired,  the  information  gathered  as  well  as  the  background  of  client  and  system 
programmers  was  believed  to  provide  a  quality  proof  of  concept  system  that  could  be  developed 
and  begin  to  alleviate  many  of  the  WRM  issues  existing  today.  Once  the  interviews  were 
completed  and  the  information  compiled,  it  was  not  long  before  intense  WRM-CA  development 
occurred. 

2.4  Risks 

As  with  any  software  development  program,  there  were  risks  that  needed  to  be  taken  into 
consideration.  Overall,  the  primary  issues  were  broken  into  two  parts:  program  risks  and 
technical  risks. 

2.4.1  Program  Risks 

One  of  the  biggest  issues  addressed  was  the  level  of  effort  necessary  to  accomplish  system 
development.  Since  the  scope  of  the  development  contract  was  to  develop  the  proof  of  concept 
software,  concentration  on  just  one  or  two  small  areas  of  development  was  not  desired.  In  depth 
research  was  needed  in  order  to  identify  requirements  from  potential  users.  This  breadth  vs. 
depth  balance  was  challenging  at  times.  Also,  when  Synergy  applied  for  and  were  accepted  to 
participate  in  JEFX  2000,  they  knew  valuable  development  time  was  going  to  be  taken  up  while 
participating  at  various  JEFX  experiment  locations.  The  aggressive  scope  and  schedule  of  JEFX 
posed  a  possible  threat  to  Synergy’s  software  development. 

2.4.2  Technical  Risks 

Of  any  of  the  risks  the  WRM-CA  team  had,  technical  risks  were  probably  the  most  prevalent. 
There  were  various  areas  within  technical  arenas  that  needed  attention. 

2.4.2. 1  System  Interfaces 

When  coming  up  with  the  ideas  for  system  development.  Synergy  knew  in  order  for  WRM-CA 
to  fully  function,  it  needed  to  access  information  from  other  Air  Force  legacy  systems.  The 
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ability  to  obtain  interface  agreements,  access  to  the  system  itself  to  gain  information  required  and 
system  classification  issues  all  weighed  heavily  on  whether  or  not  system  development  would  be 
successful. 

2.4.2.2  Data  Issues 

Another  technical  risk  encountered  was  with  data  issues  between  Air  Force  legacy  systems  and 
the  WRM-CA  development  environment.  The  quality,  timeliness  and  consistency  of  data 
between  the  legacy  systems  and  WRM-CA  as  well  as  the  existence  of  common  data  elements 
with  the  Air  Force  systems  were  major  concerns.  The  latter  of  the  two  was  the  most  important  to 
quality  integration.  If  the  data  elements  did  not  match,  it  would  be  tough  to  make  WRM-CA 
work. 

2.4.2.3  Security  Challenges 

Due  to  some  of  the  subject  matter  (i.e.,  classified  OPlans)  WRM-CA  would  access,  it  was 
obvious  WRM-CA  would  need  to  operate  in  a  secure  environment.  The  challenge  to  develop  a 
system  that  could  be  transitioned  to  a  classified  environment  yet  be  tested  in  an  unclassified 
environment.  Developers  wanted  to  make  sure  they  did  not  compromise  any  classified 
information. 

2.5  Risk  Mitigation 

After  the  risks  were  identified  an  acceptable  approach  to  mitigate  those  risks  needed  to  be 
identified.  The  following  sections  outline  the  risk  mitigation  procedures. 

2.5.1  Program  Risk  Mitigation 

The  WRM-CA  team  decided  to  concentrate  on  a  breadth  vs.  depth  balance  that  would  allow 
developers  to  touch  on  many  areas  of  system  operation,  but  not  get  extremely  deep  into 
development  of  all  of  those  areas  with  the  exception  of  a  few.  Once  again,  realizing  they  were 
developing  a  proof  of  concept  system,  and  not  a  system  to  be  fielded  at  the  end  of  the  contract 
assisted  programmers  in  deciding  what  areas  to  concentrate  detailed  development  efforts.  The 
areas  developers  would  concentrate  serious  programming  on  where  the  areas  identified  by 
potential  WRM-CA  users  as  “must  haves.” 


When  JEFX  2000  started,  Synergy  realized  much  of  the  time  spent  on  trips  to  satisfy  JEFX 
management  requirements  might  interrupt  software  development.  The  aggressive  scope  and 
schedule  of  JEFX  2000  may  also  prevent  Synergy  from  developing  the  software  to  the  level 
intended,  but  this  was  not  the  case. 

Synergy  programmers  were  not  only  able  to  develop  the  software  to  the  level  required,  but  also 
keep  in  pace  with  the  JEFX  2000  schedule.  The  result  was  a  quality,  proof  of  concept  system 
that  JEFX  2000  participants  were  satisfied  with. 

2.5.2  Technical  Risk  Mitigation 

Once  again,  the  contract  required  the  development  of  a  proof  of  concept  system  that  investigated 
the  possibilities  of  using  new  technologies  to  render  the  system  functional.  Realizing  that  this 
area  was  the  least  defined  of  all,  an  agreement  on  “how  far  was  far  enough”  on  system  interfaces, 
data  issues  and  security  challenges  was  established. 

2.5.2.1  System  Interface  Risk  Mitigation 

The  work  around  for  this  area  was  to  investigate  whether  or  not  developers  would  be  able  to  get 
access  to  the  systems  in  the  first  place.  If  they  could  not,  then  they  would  request  data  base 
schemes  that  would  at  least  allow  programmers  to  set  up  an  “exercise”  database  that  could  be 
used  for  development  purposes.  If  those  attempts  failed,  the  final  technical  report  deliverable 
would  annotate  the  results  of  the  system  interface  efforts,  as  appropriate. 

2.5.2.2  Data  Issue  Risk  Mitigation 

This  area  of  risk  mitigation  was  approached  in  very  much  the  same  way  as  the  system  interfaces. 
Data  from  Air  Force  legacy  systems  that  would  work  in  the  WRM-CA  system  needed  to  be 
obtained.  Any  issues  with  data  collection  and  consistency  would  be  addressed  in  the  final 
technical  report  for  WRM-CA  and  suggested  solutions  identified. 

2.5.2.3  Security  Challenge  Risk  Mitigation 

To  help  alleviate  this  issue,  it  was  decided  no  classified  information  would  be  used  in  its 
development  until  it  was  absolutely  necessary.  That  meant  the  interface  with  the  Joint 
Operations  Planning  and  Execution  System  (JOPES)  would  have  to  wait  until  near  the  end  of  the 
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contract  for  final  development.  Also,  the  inclusion  of  other  classified  information  such  as  the 
Wartime  Aircraft  Activity  Report  (WAAR)  would  have  to  wait  until  further  development  could 
be  done.  Appropriate  analysis  and  requirements  objectives  would  be  achieved  if  development 
were  done  in  an  unclassified  environment. 

3.  SOFTWARE  DEVELOPMENT 

3.1  Development  Process 

A  spiral  development  process  was  followed  which  was  composed  of  the  following  steps: 

3.1.1  Define  user  Requirements 

The  WRM-CA  development  team  spent  many  hours  discussing  this  subject  with  several 
individuals  who  would  have  a  stake  in  the  WRM  process.  These  persoimel  included  wing  WRM 
Officers  and  unit  WRM  monitors.  As  stated  before,  team  members  traveled  to  Korea  and  Europe 
to  discuss  the  process  and  find  out  from  users  what  they  would  want  in  a  system.  Several  hours 
were  also  spent  discussing  WRM  issues  with  AFRL  personnel,  some  of  which  had  logistics 
planning  and  WRM  management  background.  AFRL  also  assisted  us  greatly  in  ideas  for  use  of 
the  system.  The  overall  plan  was  to  visit  several  operational  bases  and  discuss  issues  with  the 
WRM  managers,  but  due  to  scheduling  conflicts,  only  a  select  few  bases  were  visited.  The 
WRM-CA  team  obtained  quality  information  from  the  bases  visited.  With  that  in  mind.  Synergy 
felt  they  received  enough  information  to  develop  a  proof  of  concept  system  acceptable  to  AFRL. 

3.1.2  Analysis 

After  Synergy  further  broke  down  the  user  requirements  provided  to  us  by  WRM  stakeholders, 
they  had  to  analyze  from  the  data  collected  what  functions  were  the  most  needed  in  the  system. 
From  the  data  collected  and  various  scenarios  developed,  use  cases  were  created  to  build  the 
system  around.  From  the  scenarios  and  stakeholder  interviews,  it  was  concluded  worldwide 
asset  visibility,  WRM  assignment  tracking,  and  awareness  of  asset  condition  were  the  most 
important  functions  required  in  the  program.  In  addition,  a  quality  search  engine  and  map 
navigation,  were  included  in  development  efforts.  The  narratives  and  use  cases  are  identified  in 
Appendix  A  and  B  respectively. 
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3.1.3  System  and  Architecture  Design 

The  system  architecture  and  application  were  refined  and  developed.  They  developed  it  as  a 
client/server  application  so  it  could  prove  that  such  an  application  could  work  for  the  Air  Force 
WRM  program.  Eventually,  developers  want  to  “webily”  the  system  so  users  can  use  it  in  an 
internet  environment. 

3.1.4  System  Testing 

After  useable  software  was  developed,  the  developers  would  test  the  system.  They  would  go 
though  each  area  of  the  software  to  correct  any  issues  and  then  continue  development  in  areas 
that  as  required.  This  iterative  approach  to  software  development  was  key  to  the  quality  of  the 
final  product.  By  developing,  releasing,  then  testing,  programmers  were  able  to  find  and  fix 
software  issues  as  well  as  continue  spiral  development.  This  approach  to  testing  was  very 
effective  and  efficient.  It  allowed  design  issues  to  be  kept  at  a  minimum  and  obtain  valuable, 
constructive  feedback  from  the  client  and  other  users.  This  approach  ensured  developers  were 
meeting  and,  in  some  cases,  exceeding  customer  requirements  and  objectives. 

3.2  System  Architecture 

WRM-CA  was  developed  using  a  distributed  component  architecture  based  on  a  J2EE 
(enterprise  environment)  and  Enterprise  Java  Beans.  Developers  did  this  for  three  main  reasons: 

Scalability  -  The  system  architecture  can  grow  as  system  needs  grow.  It  will  be  simple 
to  add  other  clients  and  servers  to  the  architecture  since  it  was  developed  to  sustain  that 
type  of  progression. 

Industry  Standard  -  Since  the  Java  programming  language  is  now  a  strong  industry 
standard  for  software  development.  Synergy  wanted  to  ensure  they  were  using  current 
techniques.  A  J2EE  architecture  reduces  the  reliance  on  a  single  vendor’s  product. 

Reusability  —  The  architecture  and  programming  language  cein  be  used  with  other  Java 
applications  with  no  need  to  convert  programming  code  into  other  forms. 

The  database  tables  used  to  show  the  database  relationships  for  the  system  architecture  are  at 
Appendix  C  and  a  diagram  of  the  high-level  system  architecture  is  at  Appendix  D. 
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3.3  Interface  Development  with  Legacy  Systems 

In  order  for  WRM-CA  to  work  properly,  data  interfaces  from  other  Air  Force  computer  systems 
were  required.  Candidates  for  data  requirements  included  the  Standard  Base  Supply  System 
(SBSS),  Core  Automated  Maintenance  System  (CAMS),  Logistics  Feasibility  Analysis 
Capability  (LOGFAC),  On  Line  Vehicle  Information  Management  System  (OLVIMS)  and 
JOPES.  Access  to  these  systems  was  necessary  in  order  to  automatically  update  the  WRM-CA 
server  and  clients  with  correct  maintenance,  supply,  transportation  and  inventory  information. 
The  following  sub-sections  provide  a  description  of  each  system,  analysis  efforts  and  each 
system’s  role  within  WRM-CA. 

33.1  SBSS 

WRM-CA  developers  wanted  to  gain  access  to  the  SBSS  server  so  they  could  filter  and  identify 
more  clearly  which  equipment  was  considered  WRM.  SBSS  designates  these  assets  as  such  by 
using  a  code  system.  WRM-CA  would  filter  out  all  assets  that  did  not  have  the  code  of  either 
“C”  or  “D.”  A  “C”  coded  item  is  considered  joint  use  WRM,  meaning  it  can  be  used  in 
peacetime  for  the  normal  ojierations  of  the  base,  but  once  a  contingency  occurs  requiring  WRM 
use,  it  is  called  back  to  the  owning  unit  and  put  into  pure  WRM  status.  Many  times,  vehicles  fall 
into  this  category.  A  “D”  coded  item  is  considered  pure  WRM.  These  assets  are  over  and  above 
the  normal  operating  stock  of  a  base  and  are  to  be  used  only  when  needed  for  contingency  or 
war.  Many  base  assets  can  fall  into  this  category. 

After  further  research  it  was  determined  an  interface  to  SBSS  was  not  required.  The  same 
information  plus  more  of  what  was  required  could  be  obtained  from  LOGFAC,  which  will  be 
discussed  later.  Although  it  was  decided  not  to  interface  with  SBSS,  no  technical  obstacles  are 
present  that  would  prevent  the  system  from  interfacing  with  WRM-CA,  should  it  ever  be 
required. 

3.3.2  OLVIMS 

OLVIMS  tracks  the  inventory  and  maintenance  records  of  all  vehicle  assets  at  an  Air  Force 
location.  WRM-CA  would  require  an  interface  with  OLVIMS  to  display  accurate  WRM  vehicle 
records.  Even  though  other  systems  provide  inventory  data,  they  lacked  specific  vehicle 
inventory  and  information  required. 
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An  interface  with  OLVIMS  was  never  established.  The  OLVIMS  system  office  had  many  other 
issues  that  had  a  much  higher  priority  than  WRM-CA;  therefore  no  extensive  interface  work  with 
OLVIMS  occurred.  Developers  were  able  to  ascertain  from  the  information  provided  that  an 
interface  with  OLVIMS  was  possible  with  no  obvious  technical  issues  present  to  prevent  it. 

3.3.3  JOPES 

The  JOPES  system  is  the  primary  operations  plan  (Oplan)  forces  tracking  tool  used  by  the  Air 
Force  and  other  military  services.  It  contains  all  unit  type  code  (UTC)  data  for  deployable  Air 
Force  assets.  Users  of  JOPES  assign  these  assets,  via  UTC,  to  a  war  plan,  which  is  then  tasked 
and  executed  eis  required.  An  interface  with  the  JOPES  system  would  allow  WRM-CA  to  obtain 
vital  OPlan  information  that  would  be  pertinent  to  the  WRM  asset  assignment  process.  Since 
JOPES  contains  the  needed  plan  information,  a  working  interface  with  JOPES  was  a  priority. 
There  were  no  serious  technical  issues  with  setting  up  an  interface  with  the  JOPES  system. 
Synergy  programmers  worked  on  the  interface  and  had  it  briefly  working  during  JEFX  2000. 
When  the  interface  occurred,  both  WRM-CA  and  JOPES  were  on  the  secure  SECRET  Internet 
Protocol  Router  Network  (SIPRNET).  There  was  no  chance  of  secure  information  being 
compromised. 

There  were  no  significant  interface  development  issues  that  would  preclude  Synergy  fi-om 
refining  and  further  developing  this  interface.  The  primary  issue  was  the  WRM-CA 
development  environment.  Since  WRM-CA  development  was  done  in  an  unclassified 
environment,  consistent  interaction  with  JOPES  could  not  occur;  therefore,  developers  of  WRM- 
CA  established  and  outlined  the  process  for  the  construction  of  the  JOPES  interface  so  system 
connection  could  occur  quickly  when  required. 

3.3.4  CAMS 

An  interface  to  CAMS  would  provide  WRM-CA  vvith  up-to-date  maintenance  records  for  the 
WRM  assets  at  a  given  base  (mainly  flight  line  type  WRM).  With  this  information  in  hand, 
users  would  have  even  more  information  available  to  make  educated  decisions  on  the  use  of 
WRM  equipment. 
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Issues  with  CAMS  involved  the  inability  to  set  up  an  interface  due  to  the  way  its  architecture  is 
configured.  CAMS  was  developed  in  a  programming  language  much  older  than  current 
languages,  therefore,  it  was  extremely  difficult  to  create  interface  framework.  For  example, 
WRM-CA  developers  would  have  no  way  to  query  the  system  to  get  any  information  without 
developing  a  totally  separate  computer  program  that  it  could  apply  to  CAMS  so  system  access 
could  occur.  Synergy  did  not  have  the  time  or  the  manpower  to  take  on  such  a  task.  One  of  the 
functional  managers  did  suggest  programmers  develop  a  “screen  scrape”  type  interface.  A 
screen  scrape  would  take  the  data  fields  from  CAMS  and  import  it  into  WRM-CA.  That  would 
only  provide  limited  information  and  not  the  critical  information  required.  Also,  the  CAMS 
office  was  very  busy  with  developing  and  establishing  a  new  system  that  corrects  the  issues  just 
discussed,  therefore,  time  for  WRM-CA  developers  to  get  guidance  and  information  from  this 
office  was  not  workable. 

3.3.5  LOGFAC 

LOGFAC  is  the  “WRM  System,”  which  means  it  contains  a  vast  majority  of  the  Air  Forces’ 
WRM  information.  The  information  obtained  from  an  interface  with  LOGFAC  would  negate 
some  interfaces  with  other  systems.  LOGFAC  stores  information  on  WRM  assets  on  the  base  in 
question,  therefore  eliminating  the  interface  requirement  for  SBSS.  As  WRM-CA  continues  to 
develop,  additional  WRM  information  LOGFAC  stores  such  as  the  wartime  consumable 
distribution  objective  and  the  wartime  aircraft  activity  report  will  be  required  for  proper  system 
operation. 

Currently,  WRM-CA  developers  have  received  the  import  process  data  for  LOGFAC,  which  is 
pertinent  to  establishing  a  system  interface.  No  major  programming  hurdles  exist  with 
developing  an  interface  with  WRM-CA. 

3.4  System  Functionality 

Once  the  interfaces  are  programmed  and  developed,  WRM-CA  will  have  the  capability  to  meet  a 
majority  of  the  user  needs.  The  main  area  Synergy  could  not  meet,  due  to  system  design,  was 
obtaining  the  asset  maintenance  information  from  CAMS.  WRM-CA  has  the  capability  to 
display  the  information  once  obtained,  but  additional  development  time  and  funding  will  be 
required.  Other  than  that  issue,  the  system  can  perform  all  user  needs.  The  following  sections 
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will  outline  and  discuss  the  most  important  user  requirements  and  how  WRM-CA  meets  the 
need. 


3.4.1  Worldwide  WRM  VisibiUty 

This  functionality  will  give  the  user,  should  they  have  the  appropriate  system  access,  the  exact 
location  of  any  WRM  equipment  in  the  world.  The  user  can  either  search  by  location  using  the 
map  function  or  they  can  search  by  asset  nomenclature/NSN  by  using  the  asset  search  function. 
This  visibility  option  is  also  expanded  by  displaying  Points  of  Contact  (POCs)  for  WRM  assets 
at  the  location  in  question  as  well  as  displaying  the  asset’s  deployment  and  unit  assignment 
history. 

3.4.2  WRM  Asset  Assignment 

WRM-CA  will  also  display  and  show,  interactively,  at  all  locations  the  assignment  of  WRM 
assets  for  contingency  or  peacetime  use.  Users  will  have  the  real-time  ability  to  distinguish  what 
equipment  goes  where  during  planning  phases.  This  will  lead  the  way  in  reducing  the 
deployment  footprint  as  well  as  put  millions  of  dollars  of  WRM  equipment  to  use. 

3.4.3  WRM  Asset  Condition 

Since  no  interface  with  an  equipment  maintenance  system  can  be  established,  WRM  asset 
condition  will  be  the  responsibility  of  the  base  WRM  monitor.  WRM-CA  could  be  modified  to 
accept  user  updates.  If  this  is  the  case,  then  WRM  asset  condition  would  be  visible  and  increase 
user  confidence  in  the  assets  would  be  established.  Not  imtil  WRM-CA  was  developed  has  there 
been  a  system  that  has  the  capability  to  display  real  time  maintenance  information  for  WRM 
assets.  In  the  past,  the  unit  WRM  monitor  tracked  asset  condition.  WRM  monitors  were  also  not 
always  provided  reliable  information  in  a  timely  manner.  With  the  advent  of  WRM-CA, 
situations  such  as  this  would  end,  providing  WRM  monitors  more  accurate  and  quality  asset 
information. 

3.4.4  Automated  Information  Technologies  (AITs) 

Currently,  web  phone  capabilities  are  resident  in  WRM-CA  by  allowing  users  to  either  deny  or 
approve  user  requests  for  WRM  remotely  (away  from  their  computer)  by  using  a  cell  phone  to 
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contact  the  WRM-CA  server.  This  capability  will  increase  coordination  and  communication 
while  decreasing  the  wait  time  for  asset  approval  or  denial. 

Additional  functionality  includes  asset  accountability  for  WRM,  where  an  interface  with  a  Radio 
Frequency  (RF)  program  will  allow  WRM-CA  to  pickup  RF  tags  and  display  the  inventory  status 
of  all  WRM  assets  at  a  location. 

3.4.5  Other  Functionality 

WRM-CA  will  also  have  the  capability  to  display  multimedia  pictures  of  WRM  so  users  have  an 
idea  of  the  physical  condition  of  the  asset. 

WRM-CA  can  generate  reports  for  selected  sites  that  will  provide  both  summarized  and  specific 
WRM  information. 

Security  measures  are  put  in  place  that  will  control  what  users  can  see  and  do  with  the  WRM 
assets.  Users  will  also  be  able  to  collaborate  real  time  with  other  users  to  help  improve 
communication  and  asset  control. 

4.  OTHER  OPTIONS 

Throughout  the  analysis  and  development  of  WRM-CA,  Synergy  came  across  several  topics  and 
areas  where  they  wanted  to  put  more  emphasis,  but  did  not  for  one  reason  or  another.  The 
following  sections  outline  these  areas. 

4.1  Lessons  Learned 

Although  the  interface  with  the  CAMS  system  did  not  materialize,  several  positive  elements 
came  out  of  that  situation.  Due  to  the  current  vision  the  Air  Force  has  adopted,  the  emphasis  on 
Agile  Combat  Support  has  been  increased  and  more  attention  has  been  placed  on  information 
technology  and  data  accuracy  than  before.  WRM-CA  provides  its  users  with  that  information 
and  data  accuracy  by  interfacing  or  providing  the  capability  to  interface  with  several  pertinent 
Air  Force  information  systems.  In  regards  to  the  issue  with  the  CAMS  system,  the  Air  Force  has 
once  again  realized  the  importance  of  accurate  and  useful  data.  They  understand  if  they  want  to 
pursue  the  WRM-CA  technology,  more  emphasis  must  be  placed  on  the  data  acquisition  from 
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older  Air  Force  systems  so  the  information  can  be  useful  to  newer  systems.  As  stated  before,  no 
major  hurdles,  with  the  exception  of  CAMS,  exist  in  the  system  interface  area.  Future 
cooperation  between  the  Air  Forces’  system  program  offices  and  WRM-CA  personnel  will 
ensure  successful  WRM-CA  integration. 

Synergy  had  also  wanted  to  try  and  design  the  system  as  more  of  a  web  tool  than  a  client  server 
system.  Although  that  was  not  part  of  the  Statement  of  Work  (SOW),  they  realized  the  Air  Force 
is  heading  toward  World  Wide  Web  (WWW)  fimctionality.  Understanding  of  this  concept  is  one 
of  the  reasons  Synergy  designed  the  system  using  Java  technology.  Therefore,  when  the  time 
comes,  the  WRM-CA  team  will  have  somewhat  of  a  smooth  transition  to  webification.  Also,  the 
Oracle  database  design  used,  the  work  towards  DII-COE  system  compliance  and  the  inclusion  of 
WRM-CA  on  other  webified  applications  demonstrates  the  desire  to  assist  the  Air  Force  with  a 
webified  WTIM-CA. 

Synergy  had  also  hoped  to  secure  and  finalize  the  interface  between  WRM-CA  and  the  current 
version  of  Unit  Type  Code  -  Development  and  Tailoring  (UTC-DT).  To  do  that,  they  would 
have  required  a  Common  Object  Request  Broker  Architecture  (CORBA)  interface  so  WRM- 
CA’s  Java  application  could  speak  to  UTC-DT’s  Delphi  application.  An  interface  between 
WRM-CA  and  future  versions  of  UTC-DT  is  a  smart  idea.  It  will  essentially  make  two  tailoring 
tools  into  one  and  allow  for  quicker  and  more  accurate  deployment  equipment  packages.  With 
UTC-DT  providing  the  “80%  solution”  after  its  initial  run,  the  WRM-CA  system  will  further 
assist  war  planners  in  tailoring  deployment  packages.  By  having  this  capability,  the  Air  Force 
will  find  it  will  make  the  48-hour  bombs  on  target  limit  and  substantially  diminish  its  logistic 
footprint  from  home  station. 

4.2  Additional  AIT  Capability 

Numerous  areas  in  this  arena  need  to  be  pursued  further.  The  concept  of  “smart”  buttons  that 
have  enough  memory  to  hold  information  on  maintenance  and  deployment  history  intrigued  the 
WRM-CA  team  as  well  as  many  laser  identification  tag  readers.  These  technologies  could  be 
used  to  better  track  WRM-CA  asset  information  in  lieu  of  other  systems  that  may  not  be  of 
benefit. 
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After  a  visit  to  Headquarters  (HQ)  Air  Force  Materiel  Command  (AFMC),  Synergy  had  all  kinds 
of  ideas  to  investigate.  They  decided  to  go  with  the  web  phone  and  RF  tag  inventory  systems 
since  we  felt  they  could  make  a  greater  impact  on  the  development  and  usability  of  the  system. 

The  options  for  AIT  application  to  this  system  seem  to  be  endless.  In  addition  to  the  buttons  and 
RF  tag  systems  mentioned  above,  there  are  bar  codes  storing  maintenance  information  that  can 
be  read  by  hand  held  devices  with  laser  scanners.  These  scanners  can  then  transfer  updated 
information  to  desktop  computer  systems  via  radio  frequency.  This  type  of  system  can  increase 
the  productivity  of  maintainers  and  decrease  delays  in  acquiring  updated  maintenance 
information.  The  relevance  of  these  systems  to  the  future  of  the  Air  Force  is  obvious.  By 
making  it  easier  for  personnel  to  perform  their  duties,  the  mission  of  the  Air  Force  will  be 
executed  more  efficiently  and  more  effectively  by  increasing  deployment  processing  speed  and 
data  accuracy.  With  this  approach  in  place,  the  Air  Force  will  continue  to  be  unstoppable  in  the 
future. 

4.3  More  Uses  of  WRM-CA 

Currently,  WRM-CA  is  a  one-dimensional  system.  Aerospace  Ground  Equipment  (AGE)  was 
strategically  used  to  develop  the  system  so  it  could  prove  the  concept  that  an  application  of  this 
type  could  work. 

4.3.1  More  Equipment 

WRM-CA  should  be  populated  with  all  WRM  equipment  and  information  (i.e.,  war  consumable 
distribution  objectives  and  wartime  aircraft  activity  reports).  This  would  include,  but  not  limited 
to,  generators  from  civil  engineering,  tracks  and  other  vehicles  from  transportation,  as  well  as 
pallets  and  nets  from  all  base  units.  It  also  could  be  used  to  track  the  maintenance  histories  of 
the  equipment  as  well  as  where  it  has  been  in  the  past.  WRM-CA  has  the  capability  to  truly  have 
complete  worldwide  visibility  of  all  WRM  assets. 

4.3.2  Munitions  and  Other  Consumables 

WRM-CA  could  also  provide  visibility  to  WRM  munitions  inventories  as  well  as  other 
consumables  such  as  petrolevim  products  and  Meals  Ready  to  Eat  (MRE). 
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Showing  visibility  to  WRM  munitions  could  assist  planners  in  creating  realistic  munitions  use 
scenarios  with  the  exact  numbers  available  and  then  have  a  concrete  plan  to  present  to  unit 
commanders  on  sortie  rates  and  munitions  use. 

Also,  having  visibility  to  the  other  consumables  on  site  can  better  prepare  deploying  forces  by 
establishing  if,  in  the  case  of  available  rations,  more  MREs  are  required. 

5.  SUMMARY 

The  concept  of  centralized  WRM  control  and  visibility  has  come  a  long  way  since  the  inception 
of  the  WRM-CA  contract  in  September  1 999.  During  that  time,  primary  issues  important  to  the 
Air  Force  WRM  program  were  ascertained.  By  providing  a  way  for  WRM  mangers  to  see  where 
and  how  much  WRM  was  available  and  that  it  would  be  set  aside  for  their  unit  to  use  when 
deployed,  were  key  contributors  to  demonstrating  the  value  and  stand  requirement  for  the 
system. 

Overall,  WRM-CA  has  merit  and  should  be  developed  further.  The  equipment  maintenance 
information  interface  needs  to  be  implemented  as  well  as  the  other  system  interface 
requirements.  Further  discussion  of  the  WRM  information  contained  in  the  system  needs  to  be 
addressed  as  well  as  future  enhancements  to  the  AIT  systems.  Also,  once  webified  and  fully 
operational,  the  system  will  be  a  tool  desperately  needed  by  warfighters  today  and  in  the  future. 

With  the  inclusion  of  only  a  small  percentage  of  the  WRM  categories  in  the  Air  Force 
represented,  the  system  proved  itself  over  and  over  with  its  functionality  and  potential.  Once 
fully  developed  and  its  full  potential  realized,  WRM-CA  will  be  a  powerful  weapon  in  the 
technological  arsenal  of  the  United  States  Air  Force. 
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GLOSSARY  OF  TERMS  AND  ABBREVIATIONS 


AEF 

AFMC 

AFRL 

AGE 

AIT 

CAMS 

CONOP 

CONUS 

CORBA 

HQ 

IDO 

JEFX 

JOPES 

LOGFAC 

LOX 

MAJCOM 

MRE 

NATO 

NSN 

OLVIMS 

OPlan 

PACAF 

POC 

POL 

RDD 

RF 

SBSS 

SIPRNET 

SOW 


Air  Expeditionary  Force 

Air  Force  Materiel  Command 

Air  Force  Research  Laboratory 

Aerospace  Ground  Equipment 

Automated  Information  Technology 

Core  Automated  Maintenance  System 

Concept  of  Operation 

Continental  United  States 

Common  Object  Request  Broker  Architecture 

Headquarters 

Installation  Deployment  Officer 

Joint  Expeditionary  Force  Experiment 

Joint  Operation  Planning  and  Execution  System 

Logistics  Feasibility/Analysis  Capability 

Liquid  Oxygen 

Major  Command 

Meals  Ready  to  Eat 

North  Atlantic  Treaty  Organization 

National  Stock  Number 

On  Line  Vehicle  Information  Management  System 

Operation  Plan 

Pacific  Air  Forces 

Point  of  Contact 

Petroleum,  Oils,  and  Lubricants 

Required  Delivery  Date 

Radio  Frequency 

Standard  Base  Supply  System 

SECRET  Internet  Protocol  Router  Network 

Statement  of  Work 
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TAV 

Total  Asset  Visibility 

UDM 

Unit  Deployment  Manager 

ULN 

Unit  Line  Number 

US 

United  States 

USAF 

United  States  Air  Force 

USAFE 

United  States  Air  Force  in  Europe 

UTC 

Unit  Type  Code 

UTC-DT 

Unit  Type  Code-Development  and  Tailoring 

WAAR 

Wartime  Aircraft  Activity  Report 

WRM 

War  Reserve  Materiel 

WRM-CA 

War  Reserve  Materiel  Capability  Assessment 

WWW 

World  Wide  Web 
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APPENDIX  A 


Narratives 


Narrative  l~Squadron  user  browses  sites  in  theater  looking  for  useable  equipment 

The  391FS  from  Mt  Home  AFB  has  been  tasked  to  deploy  12  F-15E's  to  Aviano  AB  in  support 
of  a  NATO  exercise.  The  Installation  Deployment  Officer  (IDO)  in  the  366FW  is  looking  for 
support  equipment  in  theater  to  reduce  the  airlift  required  and  decrease  the  force  closure  time  for 
the  squadron. 

The  IDO  signs  into  WRM-CA  and  selects  the  Aviano  AB  from  the  map.  From  the  popup  menu, 
the  IDO  selects  “search  for  WRM  items.”  The  search  dialog  is  displayed  and  the  IDO  restricts 
the  search  to  a  900KM  radius  aroimd  Aviano,  and  enters  the  date  range  for  which  they  will  be 
needed. 

The  IDO  initially  wants  to  find  Liquid  Oxygen  (LOX)  carts  compatible  with  the  airframes  from 
the  391st,  and  enters  the  NSN  normally  used  for  their  UTCs.  After  clicking  “find,”  the  system 
displays  a  list  of  items  with  that  NSN  which  are  unallocated  for  that  date  range.  The  list  only 
includes  three  carts,  two  from  the  warehouse  in  Sonem,  Luxembourg,  and  one  stored  at  Aviano 
itself. 

Knowing  that  some  of  the  carts  designed  for  other  airframes  may  work,  the  IDO  selects  “Find 
alternate  NSNs”  from  the  dialog  and  is  presented  \vith  another  dialog  that  allows  searching  based 
on  partial  NSNs  or  nomenclature.  Entering  “LOX”  for  the  nomenclature  search,  and  clicks 
“Find.”  The  system  displays  a  list  of  25  matching  NSNs,  the  nomenclature  for  each,  and  a 
checkbox  already  checked  to  indicate  the  system  has  selected  these  for  the  next  level  of  search. 
The  IDO  unchecks  several  items  that  are  obviously  wrong,  verifies  the  date  range  is  what  was 
entered  earlier,  and  clicks  “Find  Items.” 

The  system  displays  a  larger  list  of  various  LOX  carts  stored  in  several  locations.  Of  the 
locations,  Sonem  has  the  most  carts,  three  dozen  carts;  15  of  nsnl,  1 1  of  an  nsn2,  and  10  of  an 
nsn3.  The  IDO  selects  one  of  the  “nsnl”  items  from  the  list  and  then  clicks  “View  Item”  to  get 
more  information.  The  system  then  displays  a  screen  with  sununary  information  about  the  item, 
links  to  multimedia,  maintenance  history,  deployment  and  reconstitution  history. 

The  IDO  selects  “Save  As  HTML”  and  stores  the  report  in  a  local  file.  Returning  to  the  list  of 
items  displayed  in  the  previous  step,  the  IDO  proceeds  to  the  same  for  two  other  items  as  well. 
The  IDO  then  composes  an  e-mail  message  to  the  Petroleum,  Oils,  and  Lubricants  (POL)  flight 
chief,  attaching  the  saved  files,  asking  if  any  of  these  LOX  carts  will  work  with  the  airframes 
deploying. 

Narrative  2— Squadron  user  requests  use  of  items 

The  IDO  from  the  366FW  receives  a  reply  from  the  POL  flight  chief  stating  that  because  of  their 
unique  requirements,  they  could  only  use  one  of  the  three  different  kinds  of  LOX  carts  the  IDO 
found  earlier. 
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The  IDO  signs  into  WRM-CA  and  selects  “Request  Items”  and  the  system  responds  with  the 
Select  Plan/ULN  screen  (items  usually  are  requested  or  allocated  against  a  particular  ULN  within 
a  plan).  The  IDO  selects  the  plan  for  the  NATO  exercise,  and  the  system  displays  a  list  of  ULNs 
within  the  plan.  The  IDO  selects  the  ULN  for  the  39Ist  FS  and  clicks  “Open.”  The  system  then 
displays  the  “Find  Items”  screen. 

The  IDO  selects  “Sonem”  from  the  site  list,  selects  the  NSN  (“nsnl”)  of  the  appropriate  LOX 
cart  from  the  NSN  list,  verifies  that  the  date  range  displayed  (pulled  from  the  plan/ULN 
information)  is  correct,  and  clicks  “Find  Unallocated.”  The  system  displays  a  siunmary  list  of 
items  with  NSN  “nsnl”  at  Sonem. 

There  are  now  only  12  carts  available  (down  from  15  earlier),  and  the  list  shows  that  another  unit 
within  the  same  plan  has  requested  8  of  those  12.  The  list  also  shows  that  the  last  maintenance 
performed  on  2  of  the  unrequested  4  carts  was  before  the  last  deployment  date. 

The  IDO  selects  these  2  items,  and  selects  “Notify”  from  the  popup  menu.  The  “Item  Notify 
Options”  screen  is  displayed,  the  IDO  marks  the  “Maintenance  History”  checkbox,  marks  the 
send  e-mail  checkbox  (e-mail  addresses  are  stored  in  the  user  profiles),  and  clicks  “Notify.” 

The  system  returns  to  the  summary  list  of  items,  and  the  IDO  then  marks  the  request  checkbox 
for  all  4  carts,  as  well  as  2  of  the  carts  already  requested  by  another  unit,  and  clicks  “Request 
items.” 

Narrative  3~Ownmg  MAJCOM  WRMO  works  through  list  of  requests 

The  owning  MAJCOM  WRMO  from  USAFE  knows  there  are  multiple  requests  for  items  stored 
at  the  Sonem  warehouse  and  so  signs  into  WRM-CA  and  selects  “Sonem”  from  the  map.  From  a 
popup  menu,  the  WRMO  selects  “Review  Requests”  and  the  system  responds  with  the  Select 
Plan/ULN  screen  (items  usually  are  requested  or  allocated  against  a  particular  ULN  within  a 
plan). 

The  WRMO  selects  the  plan  for  the  NATO  exercise,  and  the  system  displays  a  list  of  ULNs 
within  the  plan.  The  WRMO  does  not  select  any  ULN  (wanting  to  see  all  of  them),  in  the  list  of 
requests  to  view  checks  “Outstanding,”  “Partially  Approved,”  “Approved,”  leaves  “Denied” 
unchecked,  and  clicks  “Open.”  The  system  then  displays  a  simunary  of  all  items  from  Sonem 
requested  by  a  ULN  in  the  plan.  After  sorting  and  summarizing  the  list  by  NSN  by  ULN,  the 
WRMO  sees  that  one  particular  item  (LOX  carts)  has  multiple  requests  for  the  same  items,  and 
the  total  requests  for  that  particular  NSN  exceed  the  number  on  hand  as  well. 

The  WRMO  is  just  coming  up  to  speed  on  the  planning  for  the  NATO  exercise,  selects 
“Organize  Collaborative  Session”  to  send  a  message  to  all  the  parties  involved  to  discuss  the 
competing  requests.  The  system  presents  a  screen  with  multiple  options  to  invite  people  to 
participate.  The  system  defaults  to  all  users  with  outstanding  requests  at  Sonem,  so  the  owning 
WRMO  only  has  to  add  the  Using  MAJCOM  WRMO  to  the  list  and  click  “Invite.”  The  system 
then  displays  a  collaboration  session  plaiming  screen  which  prompts  for  basic  information  such 
as  proposed  date  and  time  (23  Feb,  1800Z),  brief  description,  and  contact  information.  After 
filling  in  the  appropriate  information,  the  WRMO  clicks  “OK”  and  the  system  then  sends 
messages  to  all  invited  users  (WRM-CA  messages  that  will  be  displayed  the  next  time  the  user 
logs  in  as  well  as  regular  e-mail  messages.) 
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The  system  returns  to  the  summary  list,  and  the  owning  WRMO  sees  several  individual  requests 
that  can  be  dealt  with  directly.  One  request  was  for  an  inviolate  asset,  so  the  WRMO  selected 
the  item  and  clicked  “Deny  Request”  from  the  menu.  The  system  prompted  for  a  reason,  and 
after  clicking  “OK”  the  request  was  marked  as  denied,  the  screen  and  database  were  updated, 
and  a  message  was  sent  to  the  user  and  the  using  MAJCOM  WRMO. 

The  owning  WRMO  selected  the  request  for  two  light  carts,  and  clicked  “View  Details”  from  the 
menu.  After  the  system  displayed  more  information  on  the  two  items  requested,  the  WRMO 
selects  them  both  and  clicks  “Approve  Request”  from  the  menu.  The  using  MAJCOM  WRMO 
had  not  yet  processed  the  request  (both  the  owning  MAJCOM  and  using  MAJCOM  must 
approve  the  request),  so  the  system  sent  a  message  to  the  unit  and  the  using  MAJCOM  WRMO.) 

Narrative  4~Using  MAJCOM  WRMO  works  through  messages  and  requests 

Using  MAJCOM  WRMO  for  the  50th  FS  (HQ  ACC/LGXW)  receives  an  e-mail  from  the 
owning  MAJCOM  WRMO  (USAFE/LGXW)  letting  him  know  that  the  USAFE  has  approved  a 
request  by  the  20th  FW  on  the  squadron’s  behalf  for  the  use  of  two  light  carts  to  be  transported 
from  Sonem  to  a  base  in  Hvmgary.  The  ACC/LGXW  WRMO  signs  into  WRM-CA  and  the 
system  displays  a  message  screen  letting  him  know  there  are  new  messages  to  be  processed. 

The  WRMO  clicks  “Process  Messages”  and  the  system  displays  a  list  of  requests  from  ACC 
units.  By  default  it  shows  all  requests:  partially  approved,  approved,  denied,  and  outstanding. 
The  WRMO  selects  the  message  from  USAFE  for  the  50th  FS  request  and  clicks  “View 
Request.”  The  system  displays  the  request  screen  showing  a  status  of  “partially  approved”  since 
both  USAFE  and  ACC  must  approve  the  request. 

ACC  has  two  units  currently  deployed  to  the  same  base,  one  of  which  was  returmng  to  home 
station.  Both  of  the  deployed  units  were  currently  using  WRM  light  carts,  so  he  clicks  “Deny 
Request”  from  the  menu.  The  system  prompted  for  a  reason,  and  after  clicking  “OK”  the  request 
was  marked  as  denied,  the  screen  and  database  were  updated,  and  a  message  was  sent  to  the  user 
and  the  owning  MAJCOM  WRMO. 

Narrative  S—Owning  MAJCOM  WRMO  initiates  collaboration  session 

At  approximately  1700Z,  23  Feb  (an  hour  before  the  scheduled  time  for  a  collaborative  session), 
the  USAFE/LGXW  WRMO  (owning  MAJCOM)  receives  an  e-mail  from  the  system  reminding 
him  to  login  and  setup  the  session.  A  few  minutes  later,  the  WRMO  signs  into  WRM-CA  and 
the  system  displays  a  message  screen  letting  him  know  he  has  a  collaboration  session  scheduled 
for  1800Z,  and  the  WRMO  clicks  “Setup  Session”  to  initiate  the  session. 

The  system  displays  the  “Collaborative  Session  Setup”  screen  which  shows  the  list  of  invited 
users,  description  and  other  information.  The  WRMO  remembers  an  e-mail  message  from  the 
maintenance  supervisor  in  the  86MMS  at  Sembach  AB  about  delays  in  repairing  the  LOX  carts 
in  the  warehouse.  He  decides  to  include  the  supervisor  in  the  session,  and  clicks  “Invite  Other 
Users.” 

By  default  the  system  only  displays  the  users  currently  logged  in,  and  the  maintenance 
supervisor  is  not  in  the  list.  The  WRMO  unchecks  “Currently  logged  in  users  only,  selects  the 
“86MMS”  from  the  units  list,  and  clicks  “Refresh  display.”  The  system  now  shows  all  valid 


22 


users  in  the  86MMS,  and  the  WRMO  selects  the  maintenance  supervisor  and  clicks  “Invite 
Now.”  The  system  notes  that  the  user  is  not  currently  logged  in,  sends  an  e-mail  message  to  the 
supervisor  requesting  his  participation,  and  then  returns  to  the  “Collaborative  Session  Setup” 
screen. 

The  WRMO  clicks  “Start  Session”  and  the  system  displays  a  screen  with  the  current  session 
information,  currently  connected  users,  and  a  chat  box.  The  only  user  displayed  at  this  point  is 
the  USAFE/LGXW  WRMO. 

Narrative  6~Squadron  user  joins  a  collaborative  session 

At  approximately  1700Z,  23  Feb  (an  hour  before  the  scheduled  time  for  a  collaborative  session), 
the  366FW  IDO  receives  an  e-mail  from  the  system  reminding  him  a  collaborative  session  for 
WRM-CA  is  scheduled  for  1800Z.  The  IDO  remembers  discussing  this  with  the  POL  flight 
chief,  so  he  fires  off  an  e-mail  to  the  flight  chief  and  the  UDM  for  the  391st  FS  letting  them 
know  he  is  participating  in  a  collaborative  session  to  discuss  the  LOX  carts. 

Just  before  1800Z,  the  IDO  signs  into  WRM-CA  and  the  system  displays  a  message  screen 
letting  him  know  the  collaboration  session  scheduled  for  1 800Z  has  been  established,  and  the 
IDO  clicks  “Join  Session”  to  join  the  session.  The  system  displays  a  screen  with  the  current 
session  information,  currently  connected  users,  and  a  chat  box.  The  current  users  shown  are  the 
USAFE/LGXW  WRMO  (listed  as  session  lead),  the  ACC/LGLW  WRMO,  and  some  IDOs  and 
UDMs  from  other  units. 

Narrative  7— UTC-DT  user  requests  use  of  items 

The  389th  FS  at  Mountain  Home  AFB  has  been  tasked,  short  notice,  to  deploy  to  Kunsan  AB, 
ROK.  They  are  to  send  a  10-ship  F-16  package  with  all  required  support  equipment.  The  IDO, 
knowing  the  389th  has  6-ship,  12-ship  and  18-ship  deployment  packages,  boots  up  UTC-DT. 

While  using  UTC-DT,  the  IDO  enters  all  the  parameters  needed  for  the  deployment  including 
location  number  of  aircraft  deploying  and  the  time  of  year  of  the  deployment.  He  runs  the 
program  and  after  about  5  minutes,  is  given  a  first  cut  equipment  list  for  the  deployment. 

As  usual,  he  notices  there  is  a  lot  of  AGE  equipment  designated  for  deployment,  namely  bomb 
loaders,  NF-2  light  carts,  and  -86  generators.  He  decides  he  will  check  the  WRM  at  and  near  the 
deployment  location  to  see  if  the  389th  can  borrow  some  of  it. 

He  clicks  the  proper  drop  down  menu  and  selects  Kunsan  AFB  and  any  other  base  within  200 
miles.  He  sees  at  Kvmsan  there  are  several  pieces  of  WRM  available,  but  much  of  it  is  not  the 
AGE  equipment  he  is  looking  for.  He  sees  there  is  1  bomb  loader  and  2  -86s  available  for  use. 
He  checks  the  status  of  all  the  pieces  and  sees,  through  the  WRM-CA  multi  media  that  the  pieces 
look  well  worn.  He  checks  the  MX  records  of  the  equipment  and  confirms  what  he  suspected. 
All  pieces  are  down  for  maintenance  (a  hose  here  and  a  tire  there).  He  wonders  what  the  MX 
Super  would  have  to  say  about  the  MX  issues.  He  checks  to  see  who  is  currently  on-line,  notes 
that  she  is,  and  sends  her  a  message  through  the  system  and  tells  her  to  take  a  look  at  what  is 
there  and  whether  or  not  the  pieces  are  fixable. 


23 


In  the  meantime,  the  IDO  decides  to  check  the  other  locations  for  more  usable  WRM.  He 
notices  Suwon  has  much  of  the  AGE  ground  equipment  they  need,  and  in  good  shape.  He  puts 
in  a  request  for  use  of  5  NF-2  light  carts  to  help  supplement  the  airfield  lighting,  5  -86 
generators,  and  8  bomb  loaders.  If  granted,  this  request  would  completely  take  care  of  the 
requirements  for  those  equipment  pieces. 

After  about  10  minutes,  he  gets  a  message  Irom  the  MX  Super.  She  informs  the  IDO  that  none 
of  that  equipment  is  usable.  It  is  all  hard  broke.  The  IDO  responds  back  that  it  will  not  pose  a 
problem  due  to  the  request  he  made.  He  asks  her  to  share  the  request  with  her  UDM  to  get 
inputs.  He  then  passes  on  the  requests  and  information  to  the  389th  UDM  for  his  inputs. 

About  10  minutes  later,  both  UDMs  call  back  and  say  they  like  what  he  has  done  and  to  let  them 
know  when  everything  is  allocated  to  them. 

After  a  few  more  minutes,  the  IDO  receives  a  message  from  HQ  ACC/LGXW  that  the 
equipment  pieces  have  indeed  been  allocated  to  them  and  they  could  leave  home  station 
equipment  behind.  The  IDO  notifies  the  using  units  on  base  and  Aen  goes  back  into  UTC-DT 
and  sees  that  with  the  approval  entered  into  WRM-CA  has  automatically  tailored  out  those  items 
from  his  UTC. 

Narrative  8~Additional  squadron  user  joins  collaborative  session 

The  UDM  from  the  391st  FS  received  e-mail  about  their  requests  for  LOX  carts  from  Sonem, 
and  the  collaborative  session  beginning  at  1800Z.  Shortly  after  the  session  was  started,  the 
UDM  signs  into  WRM-CA.  Since  the  UDM  had  not  specifically  been  invited  to  join  the  session, 
he  clicked  “Show  current  sessions”  from  the  “Collaboration”  menu.  The  system  responded  with 
a  list  of  current  sessions  that  were  marked  as  “public,”  which  included  a  brief  description  and  an 
“open/closed”  status. 

The  UDM  selected  the  session  described  as  “Discuss  conflicting  requests  for  use  of  WRM  from 
Sonem  in  NATO  exercise”  (listed  as  open),  and  clicked  “Join  Session.”  The  system  displays  a 
screen  with  the  current  session  information,  currently  connected  users,  and  a  chat  box.  The 
current  users  shown  are  the  USAFE/LGXW  WRMO  (listed  as  session  lead),  the  ACC/LGLW 
WRMO,  the  366FW  IDO,  and  some  IDOs  and  UDMs  from  other  units. 

Narrative  9— Owning  MAJCOM  WRMO  uses  collaborative  session  to  make  allocation 
decision 

The  session  leader  (in  this  case  the  owning  MAJCOM,  USAFE/LGXW)  facilitates  the  discussion 
on  who  really  needs  how  many  items  and  where,  how  quickly  out  of  service  items  will  be 
repaired,  and  how  the  equipment  should  be  allocated.  During  the  session,  the  participants  will 
send  group  or  individual  messages  via  the  chat  screen,  lookup  related  information  on  their  own 
(maintenance  information,  multimedia,  past  deployment  history),  and  modify  their  own  requests 
or  approvals. 

At  some  point  during  the  session  the  participant  with  the  authority  do  so  (usually  the  session 
leader,  but  not  necessarily  so)  may  make  a  final  determination  as  to  the  allocation  including  any 
combination  of  approvals  and  denials,  subject  to  other  required  approvals.  (See  narrative  10, 
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“Owning  MAJCOM  allocates  equipment”).  They  may  decide  instead  to  postpone  the  decision 
until  another  collaborative  session  or  just  make  the  decision  independently. 

All  of  the  changes  to  the  information  will  be  disseminated  to  the  other  participants  so  everyone  is 
working  with  the  same  information.  The  modified  information  may  be  posted  or  abandoned  by 
the  session  leader  at  the  close  of  the  session. 

Some  collaboration  session  features 

•  Chat  session  always  available 

•  Individual  users  may  quit  the  session,  if  the  session  leader  quits,  the  session  will  end 

•  Individual  users  may  join  sessions  in  progress  subject  to  the  normal  public/private, 
open/closed  rules 

•  Main  display  to  resolve  conflicting  requests  sorted  by  site/NSN/item/requesting  ULN 

•  Two  groups  of  coliunns,  initial  and  current  zzzz 

o  Requested  quantity 

o  Status  (partially  approved,  approved,  denied,  outstanding) 
o  Allocation  quantity  (only  for  partially  approved  or  approved) 

•  Same  rules  for  modifying  information  applies  during  collaborative  session 

o  Using  units  and  MAJCOMs  who  initiated  the  request  may  change  the  requested 
amount  (current  info  column) 

o  Using  and  owning  MAJCOMs  may  change  their  approval  (add  or  remove 
approval,  add  or  remove  denial) 

o  Owning  MAJCOM  may  change  allocation  quantity 

Narrative  10— Owning  MAJCOM  WRMO  allocates  equipment  among  requesting  units 

The  owning  MAJCOM  WRMO  (USAFE  LGXW)  views  the  list  of  conflicting  requests  for  12 
available  LOX  carts  stored  at  Sonem: 

•  391st  FS  requested  6 

•  zzz  FS  requested  8 

•  999  FS  requested  4 

After  reviewing  the  requests  and  reasoning  behind  them,  the  WRMO  approves  4  carts  for  each  of 
the  units.  Of  the  4  approved  for  the  391st,  2  are  scheduled  for  maintenance  before  the  391st 
makes  use  of  them.  So  2  of  the  391®'’s  requests  were  denied,  as  well  as  4  of  the  zzz’s  requests. 
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The  items  approved  for  the  391st  won’t  be  allocated  until  their  MAJCOM  WRMO  (ACC/ 
LGXW)  approves  them  as  well.  The  MAJCOM  WRMO  for  the  zzz  and  the  qqq  has  already 
approved  their  requests,  so  after  being  approved  by  USAFE/LGXW,  they  were  allocated  the 
items  for  use. 

The  system  sent  messages  to  the  391st,  22z,  qqq  and  their  MAJCOMs  notifying  them  of  the 
approvals  and  denials. 

Narrative  11-System  administrator  updates  data  import  schedule 

The  system  administrator  receives  notice  fi'om  the  Sonem  warehouse  contractor  that  they  will  be 
providing  data  on  a  timelier  basis:  nightly  updates  instead  of  weekly  updates.  After  signing  into 
the  WRM-CA  system  administration  module,  the  administrator  selects  “Data  Imports”  from  the 
schedule  menu  and  the  system  displays  a  list  of  all  regularly  scheduled  data  import  jobs.  The 
administrator  selects  “Sonem  maintenance  data”  from  the  list,  and  clicks  “Edit.”  The  system 
displays  a  dialog  with  various  schedule  options,  with  the  current  settings  displayed.  The 
administrator  changes  the  frequency  from  weekly  on  Friday  at  2000,  to  daily  at  0300  and  clicks 
update. 

Narrative  12— Owning  MAJCOM  WRMO  browsing  WRM  usage  and  movement  for  a 
specific  plan 

The  owning  MAJCOM  WRMO  from  USAFE  knows  there  are  multiple  requests  for  items  stored 
in  theater  for  the  upcoming  NATO  exercise.  From  a  popup  menu,  the  WRMO  selects  “Review 
Allocations”  and  the  system  responds  with  the  Select  PlanAJnit  Line  Number  (ULN)  screen. 

The  WRMO  selects  the  plan  for  the  NATO  exercise,  and  the  system  displays  a  list  of  ULNs 
within  the  plan.  The  W^RMO  does  not  select  any  ULN  (wanting  to  see  all  of  them),  in  the  list  of 
items  to  view  checks  “Allocated”  and  “Pending  Allocation”  (partially  approved  requests),  and 
clicks  “Open.”  The  system  then  displays  a  summary  of  all  items  allocated  to  a  ULN  in  the  plan 
or  with  pending  allocation.  After  sorting  and  sununarizing  the  list  in  various  ways,  the  WRMO 
selects  “View  movement  summary  on  map.” 

The  system  displays  a  “Map  summary  options”  dialog  showing  a  list  of  units  deploying  as  part 
of  the  plan,  WRM  storage  sites  that  have  items  allocated  to  the  plan,  and  beddown  locations  that 
have  units  or  WRM  deploying  into  them.  The  WRMO  checks  “None”  for  “View  deploying 
sites,”  “All”  for  “View  WTIM  storage  sites,”  and  “All  WRM  employment  sites”  for  “View 
Beddown  Sites.”  For  the  “View  transportation  requirements,”  the  WRMO  checks  “Lines,” 
“Icons,”  and  “Short  tons  by  transport  mode.” 

After  clicking  “OK,”  the  system  displays  a  site  map  zoomed  out  to  fit  all  the  selected  sites. 
WRM  storage  sites  are  shown  as  a  black  triangle  inside  a  white  circle,  beddown  sites  as  green 
circles,  (beddown  sites  employing  WTIM  have  a  small  black  triangle  as  well).  There  are  lines  of 
different  widths  connecting  AVRM  storage  sites  and  beddown  sites,  the  line  width  being  larger 
for  larger  movement  requirements.  The  site  icons  have  small  text  boxes  attached  with  the  site 
name  and  total  short  tons  of  WRM  being  deployed  from  or  to  that  particular  site.  For  each  mode 
of  transport  from  the  storage  sites,  there  is  an  icon  (airplane,  ship,  train,  truck,  question  mark  for 
unknown)  with  text  showing  the  total  short  tons,  and  the  first  and  last  day  (relative  to  C-Day)  for 
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which  WRM  movement  is  scheduled  to  begin,  and  the  first  and  last  Required  Delivery  Date 
(RDD)fortheWRM. 

The  WRMO  notices  the  last  RDD  for  truck  shipments  from  Sonem  to  Aviano  appears  to  be 
wrong,  and  double  clicks  on  the  truck  icon  for  that  line.  The  system  then  displays  a  summary 
of  transportation  requirements  for  WRM  allocations  and  pending  allocations  for  all  truck 
shipments  scheduled.  At  that  level  of  detail,  the  WRMO  can  see  that  most  of  the  equipment  is 
being  transported  in  a  reasonable  time  frame,  with  a  small  amount  of  support  equipment 
scheduled  for  a  much  later  delivery.  The  WRMO  then  returns  to  the  map. 
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APPENDIX  B 


dwSjoquist,  19  Jan  2000 


A  user  has  successfully  signed  into  WRM-CA. 
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WRM-CA  Actor-Goal  Use  Case  2  -  View  WRM  Information 

[Surnmai^T”  Display  summary  information  for  a  particular  item  with  options  to  display 

j, ,  r  ,  ;  maintenance  detail,  movement  information  (part  of  a  plan),  or  deployment  history. 


dwSjoquist,  27  Dec  1999 


jSteps 


A  user  has  successfully  signed  into  WRM-CA. 


1  The  user  selects  “View  WRM  information”  (directly  or  as  a  step  in  another 
Use  case). 

2  The  user  selects  an  item. 

3  The  system  displays  summary  information  for  the  item  with  links  to  other 
information. 


Steps 

times 


4-10  are  each  optional,  may  occur  in  any  order,  and  may  occur  multiple 

The  user  views  maintenance  and  inspection  history. 

The  user  views  item  movement  information. 

The  user  views  deployment  and  reconstitution  history. 

The  user  changes  WRM  information. 

The  user  requests  the  item. 

The  user  browses  requests  and  allocations. 

The  user  requests  notification  of  changes  to  this  item. 


WRM-CA  Actor-Goal  Use  Case  5  --  Request  WRM  Item 


Request  WRM  item. 

dwSjoquist,  6  Jan  2000 

A  user  has  successfully  signed  into  WRM-CA. 

1 

The  user  selects  “Request  WRM  Item”  (directly  or  as  a  step  in  another  Use 

case). 

2 

The  user  selects  a  plan  and  ULN. 

3 

The  user  selects  an  item. 

4 

The  user  selects  a  priority  for  the  request  (low,  medium,  high). 

5 

The  user  selects  method  to  be  notified  when  request  is  processed  (e-mail,  on 
login,  etc.). 

6 

The  system  stores  the  new  request. 

The  request  is  recorded  and  all  approvers  have  been  notified. 

2 

If  a  plan  and  ULN  are  already  opened,  this  step  is  skipped. 

AsWi 

3 

If  an  item  is  already  selected  when  beginning  this  Use  case,  this  step  is 
skipped. 
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WRM-CA  Actor-Goal  Use  Case  7  —  Browse  Requests  and  Allocations 


iSummaiy 

Browse  through  list  of  selected  requests  and  allocations. 

•Actors";,  . 

Author  ',q: 

dwSjoquist,  19  Jan  2000 

;(>wherv';r'f’ 

Coniacis 

-Pre-> 

Conditions 

A  user  has  successfully  signed  into  WRM-CA. 

Steps, 

1 

The  user  selects  “Browse  Requests  and  Allocations”  (directly  or  as  a  step  in 
another  Use  case). 

2 

The  user  selects  one  or  more  requests  or  allocations. 

3 

The  system  displays  a  summary  list  of  all  requests  and  allocations  selected 
with  a  drill  down  to  view  individual  requests  and  allocations. 

■'Post^,#-. , 

Conditions 

Exceptions 

:and 

variations 

2 

If  requests  or  allocations  are  already  selected,  then  this  step  is  skipped. 
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WRM-CA  Actor-Goal  Use  Case  8  —  View  Request  or  Allocation 


Display  a  request  for  a  single  WRM  item  or  a  WRM  package. 

1'  'kK^c '-'j. 

jv'  •;-  ■;  • . 

dwSjoquist,  19  Jan  2000 

•jGotft,i^i!!;i^v,i, 

m 

A  user  has  successfully  signed  into  WRM-CA. 

,:st!ii>st^^;|#. 

1 

The  user  selects  “View  Request  or  Allocation”  (directly  or  as  a  step  in  another 
Use  case). 

''g-v 

4  -v,  /'  - :  •  ■;'■■ 

2 

The  user  selects  a  request  or  allocation. 

^I•“ 

f  '  ^1% 

-t 

3 

The  system  displays  summary  information  for  the  request,  the  various 
approvals  required  and  decisions  made,  the  status  of  the  request  and  links  to 
related  information. 

P  . r/  Y'  /  ‘  *' ' 

Steps  4-9  are  each  optional,  may  occur  in  any  order,  and  may  occur  multiple  times 
as  long  the  request  exists  (step  4  may  cancel  the  request). 

4 

The  user  cancels  or  modifies  the  request. 

•VVJ  . 

?K:;fe*SVic§lg 

'WW'^‘4 

5 

The  user  approves  or  denies  the  request. 

6 

The  user  views  WRM  item  information. 

M  \  h  - 

7| 

The  user  views  Plan/ULN  information. 

i 

8 

The  user  views  list  of  other  requests  and  allocations  for  this  item. 

i 

9 

The  user  requests  notification  of  changes  to  this  request. 

MM 

•  k  \f4Wi 

IBxb^iiitidns 

2| 

If  a  request  is  already  selected  when  beginning  this  Use  case,  this  step  is 
skipped. 

varj^ioBSv 

■Zfl4'Z%k- 

> ,. ''  J]  ..V;  V..  ”  ,  ^  ‘  v  '  < 

4 

If  the  user  is  not  the  requesting  user  (or  a  user  authorized  to  act  on  their 
behalf),  then  this  option  is  not  available. 

5: 

If  the  user  is  not  in  the  list  of  approvers,  then  this  option  is  not  available. 
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WRM-CA  Actor-Goal  Use  Case  16  ~  View  Plan/ULN 

f 

ISummaiy 

Display  a  ULN  from  a  WRM-CA  notional  plan. 

' 

.. 

l-Author 

dwSjoquist,  19  Jan  2000 

Owner 

i  Contacts 

i'Pre-  1 

j  Conditions  i 

A  user  has  successfully  signed  into  WRM-CA. 

Steps  \ 

/  •  { 

1 

-  ■  1 

,  1 

1  “  ‘  ; 

'  '  '•  1 

- ,  *  ^  ‘  ‘  '  1 

1 

1 

The  user  selects  “View  Plan/ULN”  (directly  or  as  a  step  in  another  Use  case). 

2 

The  user  selects  a  plan  and  ULN. 

3 

The  system  displays  summary  information  for  the  plan  and  the  ULN  and  links 
to  related  information. 

Steps  4-8  are  each  optional,  may  occur  in  any  order,  and  may  occur  multiple  times 

4 

The  user  views  Plan/ULN  information  for  another  ULN. 

5 

The  user  browses  requests  and  allocations  for  this  ULN. 

6 

The  user  browses  requests  and  allocations  for  this  Plan. 

7 

The  user  views  site  information  for  one  of  the  sites. 

8 

The  user  requests  notification  of  changes  to  this  Plan  or  ULN. 

Post-  :  ; 

1  Conditions : 

I::'-,  vi 

1  Exceptions 
land 

i  -  • 

1  variations  ; 

2 

If  a  Plan/ULN  is  already  selected  when  beginning  this  Use  case,  this  step  is 
skipped. 
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WRM-CA  Actor-Goal  Use  Case  17  --  View  Site  Information 
i]  Display  information  about  a  specific  site. 


dwSjoquist,  19  Jan  2000 

I.  \  '  . . . .  . . . . . .  . 


^Gciftifiiits.S:: 


'Pr^^l^^T?-  A  user  has  successfully  signed  into  WRM-CA. 


The  user  selects  “View  Site  Information”  (directly  or  as  a  step  in  another  Use 
case). 


2  i  The  user  selects  a  site 


The  system  displays  a  summary  list  of  all  WRM  items  at  the  site  with  a  drill 
down  to  view  individual  WRM  items  and  links  to  related  information. 


Steps  4-9  are  each  optional,  may  occur  in  any  order,  and  may  occur  multiple  times. 


4  ^  The  user  views  Plan/ULN  information. 


5  The  user  browses  requests  and  allocations  for  current  Plan/ULN  associated 
with  this  site. 


6  ^  The  user  views  list  of  requests  and  allocations  for  any  Plan/ULN  for  this  site. 


The  user  views  the  WRM  item. 


8  The  user  views  the  map  highlighting  this  site. 


9  The  user  requests  notification  of  changes  to  this  site. 


2  If  a  site  is  already  selected  when  beginning  this  Use  case,  this  step  is  skipped. 


If  no  plan  is  open,  then  no  links  to  ULNs  are  shown. 


WRM-CA  Actor-Goal  Use  Case  19  --  View  Site  Inventory  Information 


Browse  list  of  WRM  item(s)  or  package(s)  at  a  specific  site. 

ActoW ' 

‘Author  ' 

dwSjoquist,  20  Jan  2000 

:  ,  .  .  . . 

I'Owher' . | 

j^Contacts/: 

Conjiitiohs.- 

A  user  has  successfully  signed  into  WRM-CA. 

. 

^Stigjs  ■ 

1 

The  user  selects  “View  Site  Inventory  information”  (directly  or  as  a  step  in 
another  Use  case). 

’  "  i 

2 

The  user  selects  a  site. 

>  \  1;'-  ' 

3 

The  system  displays  a  summary  list  of  all  WRM  items  at  the  site  with  a  drill 
down  to  view  individual  WRM  items. 

Conditions  J 

Exceptions 
'■and  ' 

variations'  - 

2' 

If  a  site  is  already  selected  when  beginning  this  Use  case,  this  step  is  skipped. 
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WRM-CA  Actor-Goal  Use  Case  101  —  Sign  into  WRM-CA 


/ss-s 


ii- 

w 


iW\ 

m. 


A  user  must  successfully  sign  into  WRM-CA  before  anything  else  can  happen. 
The  sign-in  process  produces  a  user  object  which  contains  user  profile 
information  (roles,  preferences,  etc.)  that  is  used  in  the  rest  of  the  system. 


dwSjoquist,  20  Jan  1999 


4P^- 


1 


.tfe 


This  use  case  is  triggered  by  other  use  cases,  and  immediately  after  client 
system  initialization. 


The  user  enters  a  userid  and  password. 


The  system  verifies  the  validity  of  the  userid  and  password. 


The  system  constructs  a  user  profile  object  containing  roles  and  preferences 
for  the  user. 


The  system  acknowledges  the  login. 


User  successfully  logged  in,  and  user  object  with  profile  information  created  and 
passed  to  client. 
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WRM-CA  Supporting  Use  Case  119  —  Store  New  Request 


-Summaiy 

When  a  request  is  made,  it  may  require  approval  from  multiple  users  before  the 
item  can  be  allocated.  This  use  case  determines  who  must  approve  a  particular 
request,  records  the  approvals  needed,  and  notifies  all  users  involved  of  the  request. 

Actore 

ji^uthor  ; 

dwSjoquist,  7  Jan  2000 

p’n^er 

Contacts 

Pi-^ 

Conditions 

A  valid  request  object. 

Steps 

'  1 

{ 

1 

Another  use  case  triggers  this  use  case. 

2 

System  builds  a  list  of  who  must  approve  this  request. 

Steps  3-4  are  required  for  each  approver. 

3 

System  stores  information  for  approval  needed. 

4 

System  notifies  approver  or  their  proxy  of  pending  request. 

5 

System  stores  request  information. 

6 

System  acknowledges  user’s  request  along  with  approvals  required. 

Ppst-._ '  '  i 
Conditions  1 

Request  stored,  approvers  notified. 

Perceptions 

and 

variations 

4,6 

How  the  system  notifies  users  is  dependent  on  the  type  of  notification  and  user 
preferenees  stored  in  the  user  profile. 
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WRM-CA  Actor-Goal  Use  Case  124  ~  Select  WRM  Item 


Find  and  select  the  WRM  item(s)  or  package(s)  that  meet  user’s  requirement. 

dwSjoquist,  27  Dec  1999 

•Cpiimctfeyy 

1 

Another  use  case  triggers  this  use  case. 

'0im:sM!i 

2 

The  system  prompts  the  user  to  enter  selection  criteria. 

Steps  3-8  may  occur  in  any  order  and  may  occur  multiple  times.  At  least  one  of 
steps  3-7  must  occur  before  step  8.  Step  8  must  occur  at  least  once. 

3 

The  user  selects  which  sites  to  search. 

4 

The  user  selects  which  NSNs  or  nomenclature  to  find. 

5 

The  user  selects  maintenance  status  to  include. 

6 

The  user  selects  allocation  status  to  include. 

1 

The  user  selects  plan  and  ULN  again  std 
which  to  check  allocation  status. 

8 

The  user  selects  “Search”  and  the  system  displays  items  current  selection 
criteria. 

tes» 

9 

The  user  selects  one  or  more  items  from  the  list. 

iC6¥aiti0ii&| 

One  or  more  WRM  items  (by  serial  number)  have  been  selected  by  the  user. 

'Exlef^^olts} 

yanatious  ^ 

8 

If  no  matching  items  are  foimd  the  use  case  may  not  proceed  to  step  9  (so  the 
Use  case  fails  if  no  further  selections  are  attempted). 
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WRM-CA  Supporting  Use  Case  125  —  Store  Approval  or  Denial  of  Request 


Siimniaiy 

For  each  approval  required  for  a  request,  the  approving  user  must  make  a  decision 
of  “approval”  or  “denial.”  A  single  denial  from  the  list  of  approvals  required  makes 
the  request  status  “denied.”  All  required  approvals  must  be  “approved”  to  change 
the  status  to  “approved”  (which  then  triggers  the  actual  allocation).  If  any  required 
approvals  are  undecided  (pending),  then  the  request  status  is  “pending.” 

Actors 

Author 

dwSjoquist,  20  Jan  2000 

Owner 

Contacts 

Pre- 

Conditions 

A  valid  request  object  and  a  decision  (approval  or  denial). 

Steps 

1 

Another  use  case  triggers  this  use  case. 

2 

System  verifies  the  user  profile  matches  the  approver  role  assigned  to  this 
request. 

3 

System  updates  request  information  with  decision  (approval  or  denial). 

4 

System  updates  status  of  request. 

5 

System  notifies  requesting  user,  and  other  users  who  are  listed  as  approvers  of 
this  request. 

Post- 

Conditions 

Request  updated,  requestor  and  other  approvers  notified,  allocation  performed 
where  appropriate. 

Exceptions 

and 

:yariations 

h-'..  ■  -■ 

i 

4 

Denial 

The  request  status  is  changed  to  “denied.” 

Approval 

If  any  other  required  approval  is  “denied,”  the  status  is  left  as 
“denied.” 

If  any  other  required  approval  is  “pending,”  the  status  is  left  as 
“pending.” 

If  all  other  required  approvals  are  “approved,”  the  status  is 
changed  to  “approved”  and  the  item  is  allocated. 

5 

How  the  system  notifies  users  is  dependent  on  the  type  of  notification  and 
user  preferences  stored  in  the  user  profile. 
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APPENDIX  C 


WRM-CA  Data  Tables 
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APPENDIX  D 


System  Architecture 
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